Removed an unnecessary TODO message and reverted a class name change for BaseHTTPTransport.

GH-4568

Adds test coverage for the error handling path when HTTP requests return
error status codes.

GH-4568

Restore comments accidentally removed during a previous commit.

Refactored class names such that BaseHttpTransport now has the same functionality as before the hierarchy refactor

GH-4568

Add a new flush_async method in the Transport ABC. This is needed for the async transport, as calling it from the client
while preserving execution order in close will require flush to be a coroutine, not a function.

GH-4568

Move flush_async down to the specific async transport subclass. This makes more sense anyway, as
this will only be required by the async transport. If more async transports are expected,
another shared superclass can be created.

GH-4568

Add necessary type annotations to the core HttpTransport to accomodate for async transport.

GH-4568

…nd cleaner return paths

GH-4568

GH-4568

Add a new implementation of the transport background worker based on an
async task. This worker mostly mirrors the same functionality as the
thread-based worker, with the exception that it exposes a non-blocking
async flush (which can be awaited from an async context). Furthermore,
the worker itself is not thread-safe and should be called using
[run_coroutine_threadsafe](https://docs.python.org/3/library/asyncio-task.html#asyncio.run_coroutine_threadsafe)
or similar when called from another thread (this is fixed and handled by
the transport). I have kept the fork check from the threaded worker, but
I am not sure if it is necessary as forking in an async application
would also break the event loop.

GH-4581

---------

Co-authored-by: Neel Shah <[email protected]>

Integrate the async transport with the rest of the SDK. Provide a new
experimental option `transport_async` that enables the async transport
if an event loop is running. Otherwise, fall back to the sync transport.

Furthermore, adapt the client to work with the async transport. To this
end, flush and close were changed to be non blocking and awaitable in an
async context to avoid deadlocks, however close enforces a completed
flush before shutdown. As there are to my knowledge no background
threads running flush/close, these methods are currently not
thread-safe/loop-aware for async, which can be changed if necessary.

Atexit issue: The atexit integration used by the SDK runs after the
event loop has already closed if asyncio.run() is used. This makes it
impossible for the async flush to happen, as atexit calls
client.close(), but a loop is no longer present. I attempted to apply
[this fix](https://discuss.python.org/t/atexit-for-asyncio/13911) by
patching the loop close in the asyncio integration, but I am unsure if I
did it correctly/put it in the correct spot, or if this is a good idea.
From my SDK test however, it seems to fix the flush issue. Note also
that this will apparently be patched in Python 3.14, as per the
discussion in the linked thread.

As a final note, I added event loop checking. Whenever the event loop is
used, the transport/client catch RuntimeErrors, which would be thrown in
case the event loop was already shut down. I am not sure if this is a
case we need to consider, but I added it for now because I did not want
the transport to potentially throw RuntimeError if the event loop is
shutdown during a program. If this should be left out currently for
simplicity, I can remove it again.

I added the [httpcore[asyncio] ](https://www.encode.io/httpcore/async/)
dependency to requirements-testing, as it is needed for the async
httpcore functionality.

GH-4601

---------

Co-authored-by: Neel Shah <[email protected]>